Hi @SannidhyaSah, thanks for this contribution! The ability to connect to various OpenAI-compatible endpoints is a great addition.

Regarding the introduction of the OpenAiCompatibleEmbedder class:

The new OpenAiCompatibleEmbedder shares a significant amount of its core logic (batching, retries, API client interaction) with the existing OpenAiEmbedder. Given this similarity, and considering that the system currently relies on a predefined list of models in EMBEDDING_MODEL_PROFILES rather than dynamically fetching model lists from the compatible endpoints, an alternative approach could be to enhance the existing OpenAiEmbedder.

We could potentially modify OpenAiEmbedder to accept an optional baseUrl in its constructor. If provided, this baseUrl would be used when instantiating the OpenAI client; otherwise, it would default to the standard OpenAI API URL.

This doesn't mean your implementation is wrong. However, it's an architectural consideration that might lead to a slightly more streamlined codebase in the long run.

What are your thoughts on this?

Hi @SannidhyaSah, thanks for this contribution! The ability to connect to various OpenAI-compatible endpoints is a great addition.

Regarding the introduction of the OpenAiCompatibleEmbedder class:

The new OpenAiCompatibleEmbedder shares a significant amount of its core logic (batching, retries, API client interaction) with the existing OpenAiEmbedder. Given this similarity, and considering that the system currently relies on a predefined list of models in EMBEDDING_MODEL_PROFILES rather than dynamically fetching model lists from the compatible endpoints, an alternative approach could be to enhance the existing OpenAiEmbedder.

We could potentially modify OpenAiEmbedder to accept an optional baseUrl in its constructor. If provided, this baseUrl would be used when instantiating the OpenAI client; otherwise, it would default to the standard OpenAI API URL.

This approach might offer a few benefits:

* **Reduced Redundancy**: Avoids adding a new class that largely duplicates existing functionality.

* **Simplified Configuration**: The list of embedder providers in the settings would remain shorter, with the "OpenAI" provider gaining an optional "Base URL" field.

This doesn't mean your implementation is wrong. However, it's an architectural consideration that might lead to a slightly more streamlined codebase in the long run.

What are your thoughts on this?

@daniel-lxs I see the benefit of your proposed change in reducing the scope of modifications. My primary concern, though, is the potential for user confusion if we embed this within the OpenAI embedder. Given that the OpenAI compatible provider class functions as a universal proxy for other providers, not able to distinguishing between the two could become a UX nightmare.

That said, I've gone ahead and implemented your suggestion to see it in practice. If you're confident that the user confusion risk is acceptable, I'm ready to push these changes.

@SannidhyaSah
I think it would make sense to separate them in the case that the new provider allows the user to fetch or add new models, but since the models are exactly the same it might not be as confusing.

Here's one example:

Even though the provider is OpenRouter the user is able to set their own base URL.

Let me know what you think.

@SannidhyaSah I think it would make sense to separate them in the case that the new provider allows the user to fetch or add new models, but since the models are exactly the same it might not be as confusing.

Here's one example:

Even though the provider is OpenRouter the user is able to set their own base URL.

Let me know what you think.

@daniel-lxs I appreciate your insight on how identical models might reduce immediate confusion, and I certainly see the logic in that perspective.

However, my concern about potential user confusion in the long run remains, especially given the broader and evolving landscape of embedding models and the distinct, crucial role our OpenAICompatible provider already plays. As you mentioned this will come in handy when new provider allows the user to fetch or add new models , but alredy exist .. For instance, other providers like Mistral AI not only offer their own embedding models, as seen here: https://docs.mistral.ai/capabilities/embeddings/code_embeddings/, but they also frequently provide free access to their APIs, which is often a strong preference for many users.

Beyond that, our OpenAICompatible endpoints are incredibly valuable for users connecting to local model hosting solutions like LM Studio and Ollama. For those using Open Web UI with Ollama to host their models on a VM, this integration is a real lifesaver. This makes the OpenAICompatible method a truly essential way for users to interact with a wide array of providers and their self-hosted models.

Looking further ahead, maintaining this as a completely separate class for OpenAICompatible providers will actually significantly reduce the need to add any other new embedder classes in the future, as it's designed to be a flexible gateway. Furthermore, having it as a distinct class offers a critical security and stability benefit: if we ever need to adapt or modify something specifically for these external or compatible models, we only need to work within the OpenAICompatible class. This approach keeps the main OpenAIEmbedder class undisturbed, ensuring it remains the most secure and stable option for direct OpenAI integrations.

Therefore, maintaining this clear architectural separation between the OpenAI embedder and the broader OpenAICompatible provider helps ensure users don't get confused as they navigate various embedding options, both now and in the future, while also streamlining our maintenance and future development efforts.

I can add a logic to fetch the models dynamically . That will resolve most of the future problems we might face here.

Let me know your thoughts so that I can proceed accordingly.

@SannidhyaSah
Do you know of any OpenAI compatible provider that also serves the OpenAI text-embedding-ada-002, text-embedding-3-small and text-embedding-3-large?

I just don't think adding another provider to just have these same models in the list would be too useful for the users.

Let me know what you think.

oh i see the confusion here .
@daniel-lxs what if i remove the hardcoded models from this new provider class completely . That was an oversight on my side . What if we have a function to fetch the dynamically instead here. Just like it's done in the normal Open AI compatible providers for chat completions. Does it solve the problem ? What do you think ?

@SannidhyaSah Yes! That was my idea, if we can somehow dynamically list them then it totally makes sense to have a separate provider for it.

Yeah what we do in the OpenAI Compatible provider in general is to try to list the models using /v1/models, but to also let the user enter their own model name in case that listing endpoint doesn't work.

For what it's worth one use case I heard about recently is people who want/need to use LiteLLM to proxy their model calls. In this case it's the same models, but through a proxy to meet their company's requirements.

Testing on LM Studio

OpenAI Provider for Embeddings Testing.pdf

Apologies for the PDF, I am still trying to figure out getting MD files out of Obsidian easily

Hey @adamhill,

We are using the OpenAI client to create the embeddings, it seems like LM Studio is not 100% compatible if it's failing like this. I tested with OpenAI and it works without any issues.

In that case is probably better to wait for the LM Studio provider.

FYI. Per the OpenAPI specs v1/embeddings/ is the correct URL, no /models/ in-between as shown in the LMS developer console coming from Roo. Am I misinterpreting the specs?

https://platform.openai.com/docs/api-reference/embeddings/create

Edit: cURL works against LMS

• no /models/ in the URL
• normal model ID

curl http://10.5.1.251:1234/v1/embeddings \
 -H "Authorization: Bearer $OPENAI_API_KEY" \
 -H "Content-Type: application/json" \
 -d '{
   "input": "The food was delicious and the waiter...",
   "model": "nomic-embed-code",
   "encoding_format": "float"
 }'

{
 "object": "list",
 "data": [
   {
     "object": "embedding",
     "embedding": [
       0.02144342102110386,
       -0.010139767080545425,
       -0.01469159685075283,
       
       ....

LMS Logs

2025-06-04 15:23:15  [INFO] 
Received request to embed: The food was delicious and the waiter...
2025-06-04 15:23:15  [INFO] 
Returning embeddings (not shown in logs)

@adamhill
We are not calling any endpoints with anything other than the OpenAI client itself, and it works when I tested it with OpenAI.

I'm not sure what's going on with LM Studio but we basically are just using the official OpenAI client, this PR only passes a different base URL.